1. Field of the Invention
The present invention relates to the fields of computer operating systems, distributed multi-processing hardware systems, object oriented programming, data caching, file systems, and virtual memory systems. More particularly, the present invention relates to improved techniques for establishing and efficiently extending the functionality of traditional file systems by using a set of dynamically configurable layers.
2. Description of Related Art
Vnode interface as described in "Vnodes: An Architecture for Multiple File System Types in Sun UNIX," by Steve Kleiman, Summer USENIX 1986, June 1986, is an architecture that allows multiple file system types to co-exist within an operating system (OS). Vnode is an abstraction of a file and is used by the OS to access files in file systems of different types without knowing how the file operations are implemented in those different file systems. Over the years, several flaws of the vnode interface have been discovered. These include flaws such as: (1) a single vnode interface represents the interfaces of several different OS objects, such as files, directories, and devices; and (2) a vnode combines file access with file caching.
Traditional operating systems, such as UNIX.RTM. (UNIX is a Registered Trademark of AT&T), provide a vnode interface or a vnode-like file system switch that is used to add new file systems to the OS. Such interfaces, however, are complex and cannot be invoked from remote machines. Moreover, the vnode interface is a cumbersome interface--i.e. it provides all the interfaces that a file system may need and a new file system has to implement all of the interfaces regardless of whether the new file system will provide a complete set of functionality.
FIG. 1 illustrates a prior art vnode 1 with a system call processing unit 3, a data caching unit 5 and a storage management unit 7. Storage management unit 7 interfaces with a storage system 9 through a device driver interface 11.
As described above, one problem with prior art vnode 1 is that it contains an interface that is a "super-set" of several interfaces. Vnode 1 contains functionality for carrying out operation on behalf of system calls, operation call from virtual memory manager to participate in data caching, and functionality to control the storage of data. For example, in Sun Microsystems, Inc., Solaris.RTM. 2.4, a vnode would have to implement 42 operations.
Another problem with vnode 1 is that it combines the function of the file access and file caching interfaces. By having these two functions in a single object, it is impossible to implement the occurrences in a distributed system where there are multiple caches for a single file.
In both "Evolving the Vnode Interface," by David S. H. Rosenthal, USENIX 1990, June 1990 (Rosenthal), and "Stacking Vnodes: A Progress Report," by Glenn C. Skinner and Thomas K. Wong, Summer USENIX 1993, June 1993 (Skinner), a description is contained to make the vnode interface more extensible. Both Rosenthal and Skinner describe the creation of a stack of vnodes and utilizing frameworks for managing the stack. However, the protocols described by both Rosenthal and Skinner assume that all vnodes in the stack are in the same address space. Neither Rosenthal nor Skinner considers: (1) composing stacks where some of the vnodes would be located in the kernel and other vnodes located in the user space, or (2) distributing vnodes on multiple computer nodes in a distributed system. It is not clear how the frameworks described by Rosenthal and Skinner would support a coherent distributed file system.
In "Extensible File Systems in Spring," by Yousef A. Khalidi and Michael N. Nelson, SMLI TR-93-18, Sun Microsystems Laboratories, Inc., September 1993 (Khalidi), a flexible framework for extensible file systems is presented which applies to a distributed object oriented operating system. However, the framework provided by Khalidi is incompatible with traditional operating systems such as UNIX and therefore cannot take advantage of existing applications configured for executing in a UNIX environment. Thus, it is considered highly desirable to develop a framework with the same flexibility as in Khalidi which could be applied to traditional operating systems. Such a framework would support inter-operability between the traditional operating systems, such as UNIX, and new operating systems, such as the Spring operating system as described by Khalidi. Thus, it is desirable to enable a vnode-based system to support flexible, extensible file system building that is tailored for a distributed system, without having to re-write or throw away the current investment in the OS code.